[アップデート] AWS Migration Hub Refactor Spaces で ネットワークブリッジをプロビジョニングせずに環境を作成出来るようになりました

いわさです。

本日 AWS Migration Hub の Refactor Spaces にアップデートがありました。

ネットワークブリッジをプロビジョニングせずに環境を作成出来るようになったとのこと。
Migration Hub Refactor Spaces って何？ネットワークブリッジって何？という状態だったので、これは良い機会だと思いましてアップデート確認を兼ねて触ってみました。

まず Migration Hub Refactor Spaces は re:Invent 2021 で発表された新サービスで、アプリケーションをサービスごとに切り出してリファクタリングやマイグレーションを支援するためのサービスです。
以下の記事でとてもわかりやすく解説されているのですが、移行前のアプリケーションの前段にプロキシとなる API Gateway を配置し、サービスごとにルーティングを変更することでサービス利用者のインターフェースはそのままで新環境へ部分的に移行していくことが出来ます。

Transit Gateway の自動プロビジョニングが必須ではなくなった

まず、Refactor Spaces を使う際には API Gateway が前段に必ず登場します。
そして統合先の移行元アプリケーションなどには VPC リンクを使ってプライベートネットワーク経路で統合します。
このプライベートネットワークへの統合のために、従来は Refactor Spaces をデプロイした際に自動で Transit Gateway が作成されていました。

今回のアップデートで Transit Gateway の自動プロビジョニングはオプションとなりました。
これによって、例えば同一アカウントの単独な VPC のみであれば API Gateway からそのまま VPC リンクのみで移行元サーバーへ接続したり、あるいは複数 VPC の場合でも VPC ピアリング経由で接続するなど Transit Gateway を使わないオプションが選択出来るようになりました。

VPC ピアリングパターンで試してみる

今回は移行元サービスとプロキシ環境用の２つの VPC を VPC ピアリングで接続し、Transit Gateway なしでアプリケーション環境を用意してみます。

環境の新規作成時に「ネットワークブリッジ」の「クロスアカウント接続用のネットワークブリッジをプロビジョニングする」をオフにします。
デフォルトはオフです。環境作成後には変更出来ないのでご注意ください。

作成された環境では次のように「Bridge」欄に何も表示されません。

API Gateway の VPC リンクを配置するプロキシ VPC を指定します。

プロキシ VPC と移行元アプリケーションサーバーの VPC をピアリング接続します。
移行元アプリケーションサーバーでは Apache を起動させています。

$ curl http://localhost/hoge1/hoge1.html
hoge1
$ curl http://localhost/hoge2/hoge2.html
hoge2
$ curl http://localhost/
hoge index

最後に、通常どおりサービスを作成しデフォルトルートを作成します。
エンドポイントは移行元アプリケーションサーバーのプライベート IP アドレスを指定しています。

% curl https://zyw7uflko3.execute-api.ap-northeast-1.amazonaws.com/prod/hoge1/hoge1.html 
hoge1
% curl https://zyw7uflko3.execute-api.ap-northeast-1.amazonaws.com/prod/hoge2/hoge2.html
hoge2
% curl https://zyw7uflko3.execute-api.ap-northeast-1.amazonaws.com/prod
hoge index

自動でルートテーブルなどの管理はされない

なお、ネットワークブリッジモードを使わない場合だと自動でルートテーブルの設定などはされません。
柔軟性はありますがルートテーブルの設定や VPC ピアリングの設定は自分たちでしっかり設定する必要があります。

作成される API Gateway リソース・メソッドはネットワークブリッジモードの時と同じで、VPC リンクを経由してピアリングしている移行元アプリケーションサーバーを指しています。

ルートテーブルは独自で管理するので、直接 Direct Connect や VPN を経由することも出来そうですね。

ネットワークブリッジモード

ネットワークブリッジモードを選択すると、従来どおり Transit Gateway が作成されます。

そして、作成された Transit Gateway は Refactor Spaces によって管理されているので、サービスとルートの構成内容に応じて Transif Gateway ルートテーブル情報も自動で構成されます。

さいごに

本日は AWS Migration Hub Refactor Spaces で ネットワークブリッジをプロビジョニングせずに環境を作成出来るようになったので実際にサービスを作成して確認してみました。

今回初めて Migration Hub Refactor Spaces 使ったのですが、これすごく良いですね。
移行期間中のコストは対象かかりますが稼働している状態で少しづつ移行出来るので使い所ありそうです。

従来は次のユキチバさんの記事のように、小規模な構成だと使われない Transit Gateway が作成されてしまうケースがあったのですが、今回のアップデートで無駄な Transit Gateway は作成せずに単独 VPC や VPC ピアリングを使うことも出来るようになって導入しやすくなったのではないでしょうか。